Software development is becoming increasingly complex and sophisticated. In addition, as computers and embedded controllers are increasingly used in products that were traditionally not computer-based, software development has become an important task for new types of products and new types of manufacturers. For example, in the automotive and electronics industries, software is quickly becoming a major piece of the overall deliverable products. Moreover, the increasing complexity and integration into other products has required greater collaboration between parties, e.g., original equipment manufacturers (OEM's) and suppliers.
Typically, OEM's and suppliers each have their own unique software development environments that are used to develop, test and track problems with deliverable software. In many cases, some of these parties are not particularly well equipped to handle software development, particularly if such parties predominantly provide manufacturing or design of products where software is only a small part of the overall design.
In many situations, it is desirable to allow multiple parties working on a common project to share information between their respective software development environments. One particular area in which collaboration is desirable is that of problem tracking. In particular, software development environments often include problem tracking systems that are used to generate problem reports reflective of errors or defects in a particular product. Problem reports typically include information such as an identification of a problem, a description of the cause, a description of the source of the problem, as well as additional information such as the identification of a responsible party and the severity of the problem. Problem reports are typically logged and stored in a database, as well as forwarded to responsible parties for resolution.
Problem tracking systems, by themselves, are unable to transmit problem reports across different development environments. As a result, cross-development environments (CDE's) have been developed to bridge multiple software development environments and allow collaborative operations to be performed between multiple such environments.
As an example, a CDE may be used to bridge the software development environments of an OEM and a tier one supplier. The OEM may include a problem tracking system in its software development environment that is used for tracking software and hardware related problems by release and component. Likewise, the tier one supplier, which may develop software on behalf of the OEM, may have a problem tracking system that tracks only software related problems by release and component. The OEM and tier one suppliers releases and components are typically different. An OEM may be working on a release 20A of a component X, while the tier one supplier may be working on release 2.1 for a component Y.
As soon as a tier one supplier makes a delivery of its software to the OEM, there is a need to track problems between the two systems. A CDE addresses this need by mapping the problem tracking systems at different sites so that project managers and developers can create, view and report on problems in both locations.
A CDE is typically implemented by creating a process that maps together multiple systems. Environmental mappings, typically stored in mapping data structures, are used to map command, parameters, and values in one software development environment into a format compatible with another software development environment. Exit support, usually provided in the interfaces of each software development environment, is typically utilized to interface the software development environment with the CDE. Under this scenario, a software development environment at one site is able to issue a transaction to the CDE that is then mapped to a format acceptable to one or more destination software development environments, resulting in transmission of a transformed transaction to the destination environment(s). The overall operation performed in this scenario may be referred to herein as a multi-site transaction.
While a CDE satisfies the need to communicate between multiple systems, a CDE can introduce a number of new points of failure that can compromise the ability of multiple software development environments to maintain a consistent state. In part, this is due to the fact that a CDE typically does not maintain its own central database, but rather relies on the individual software development environments to maintain their own data. A CDE is also not intended to affect the native tools in a software development environment, or require much, if any, dedicated functionality in each software development environment to support the CDE.
However, in part due to these factors, it has been found that a CDE process is often vulnerable to changes in individual development environments. In particular, the mappings between environments are highly dependent upon the software development environments remaining stable. Whenever a software development environment changes, e.g., by adding a new release, product or component, the mappings can become obsolete. Similarly, whenever new commands, parameters or values are added to the underlying software development environment, the mappings can also become obsolete.
Without intervention by an administrator to update the mappings, errors may be generated as a result of a transformation applied by a CDE, resulting in no “multi-site” transaction. Failure of such a transaction may cause a number of problems. For example, in the case of problem tracking, a failure in a multi-site transaction may result in a problem report not being forwarded to a destination software development environment, and as such, a failure to report a problem to the developers and project managers at that site.
Additional failure mechanisms in a CDE may result from failures in the CDE itself and/or in one or more software development environments. If the CDE process cannot run, e.g., due to hardware failures, over-capacity, or communication errors, the CDE is unable to transform a transaction, thus resulting in the failure of the transaction. Likewise, if the destination system is unavailable, e.g., due to hardware failure, communication failure, etc., the CDE will likewise fail to complete the transaction.
Therefore, a significant need exists in the art for a manner for maximizing the availability and minimizing interoperability problems that arise in a cross development environment.